2024-11-17 external brain thinking

https://gyazo.com/3917ba7c677367b442dfd29ecda7f8af

So it's not that the translation has stopped, but that the import is mocking it up.

but it doesn't have the data, it just hits Scrapbox's API when accessing it and renders it.

Good features:.

Custom Domain Delivery with Vercel

Free UI design

Bad features:.

Data is acquired via Scrapbox's API without a DB, so processing using data that cannot be obtained from Scrapbox is not possible.

Read.

Issues/needs of crossing multiple projects

Needs to span multiple services

Automatic English translation.

Good features

You're straddling the language barrier.

Bad Characteristics

Difficult to indicate in the UI that the view is a translation since it is a Scrapbox

Also related to [Vector Search in Nishio

The data is automatically taken and EMBEDDED.

Experimental search across multiple projects.

Is this PRIVATE?

embedding side

I created omoikane-embed and then applied it to /nishio.

Perimeter Search

static rendering

Three points of contention are scalability, communication with others, and website publication.

Good organization, I was thinking to myself as I wrote this far, "You have multiple needs mixed up that need to be resolved.

My needs are not necessarily equal to this, so I have to think it through myself properly.

Obsidian or Scrapbox is a false choice

Since "flexible in expansion" is vague, make it a little clearer what kind of expansion you want to do.

I want to extend the View.

Backend can remain Scrapbox.

Scrapbox can continue to be used for the Japanese real-time part.

The conversion delay is not a problem because it is a replacement for what was originally translated into English and published at a rate of once a day.

I've been importing into Scrapbox.

But then, for those for whom English is not their native language in the first place, it would simply be "a site that for some reason cannot be machine translated"?

Frustration with not being able to add to the UI that it is a translation.

I'm feeling like I don't want to rely on the "rewrite services without a write API by importing" hack anymore, since imports are now mocking me up.

I'm thinking that the same mechanism could be used to host the Japanese version, and that new features could be added along the way.

The problem that because there are so many things we want to do, we have to raise the level of abstraction to be able to do them all, and as a result, we get too far away from the specific requirements, which reduces the clues for decision making.

Should we limit ourselves to English hosts for once?

There is a lot to be learned from actually doing it.

Unknown if the Obsidian path should be followed in replacing View

V4 was released on 2023-08-20 and the configuration has changed significantly

I wasn't used to writing Hugo templates, so being able to customize the front end with JSX would be helpful.

Whoa, you can customize it with JSX, React-like.

Create a new one with external-brain or something.

Save JSON

Create Japanese-English Obsidian format with [ScrapboxToObsidian

Quartz v4 to Github Pages

(/nishio-en and mem.nhiro.org are operated in parallel without erasing once)

imagination

/nishio-en will not be updated as it is, and when it works with GitHub Pages, I'll pin the "see here" page and be done with it.

MEM is another story.

I'd like to see them join forces in the long run, but not at this point.

Interesting things to do with embedding data could be derived from omni.

---